1. Field of the Invention
The present invention relates to information processing technology. More particularly, the present invention relates to a system and method for parent class objects to create child objects with increasing specificity regarding a system situation.
2. Description of the Related Art
One of the highest priorities of information technology (IT) organizations responsible with managing mission-critical computing environments is to ensure that problems, as well as conditions that could lead to problems, are handled in a timely and efficient manner. Events may come from a variety of sources. Examples include events that occur: (1) when a link to another computer system goes down, (2) when a router used for routing information goes down, (3) when a database is down, (4) when the system processor is maximized, or xe2x80x9cpegged,xe2x80x9d for an extended period, (5) when a disk is full, (6) when one or more applications that make up a critical business function (i.e., order entry) go down, (7) when a critical application program""s performance degrades beyond an acceptable level, and (8) when a host computer is going down.
As used herein, a xe2x80x9cbusiness systemxe2x80x9d serves the needs of the organization""s critical functions, such as order entry, marketing, accounts receivable, and the like. A business system may span several dissimilar types of computers and be distributed throughout many geographical locations. A business system, in turn, is typically based upon several application programs. An application program may also span several dissimilar types of computers and be distributed throughout a network of computer systems.
An application typically serves a particular function that is needed by the business system. An individual application program may, or may not, be critical to the business system depending upon the role the application program plays within the overall business system. Using networked computers, an application may span several computer systems. In an Internet commerce system, for example, an application program that is part of the company""s order processing business system, may be responsible for serving web pages to users browsing the companies online catalog. This application may use several computer systems in various locations to better serve the customers and provide faster response to customer inquiries.
The application may use some computers running one type of operating system, for example a UNIX-based operating system such as IBM""s AIX(copyright) operating system, while other computer systems may run another type of server operating system such as Microsoft""s Windows NT(copyright) Server operating system. Individual computer systems work together to provide the processing power needed to run the business systems and application programs. These computer systems may be mainframes, mid-range systems, workstations, personal computers, or any other type of computer that includes at least one processor and can be programmed to provide processing power to the business systems and applications.
Computer systems, in turn, include individual resources that provide various functionality to the computer systems. For example, a modem is an individual resource that allows a computer system to link to another computer system through an communication network. A router is another individual resource that routes electronic messages between computer systems. Indeed, even an operating system is an individual resource to the computer system providing instructions to the computer system""s one or more processors and facilitating communication between the various other individual resources that make up the computer system. Events, as described herein, may effect an entire business system, an application program, a computer system, or an individual resource depending upon the type of event that occurs.
The number and types of events that may occur vary widely from system to system based upon the system characteristics, load, and desired use of the system. A business system providing content from an Internet site may experience different events than a business system used to process a the company""s payroll. However, many events between dissimilar systems overlap. For example, many computer systems experience problems when the disk space is full and many computer systems experience problems when the system""s processor is pegged. The types of problems these events cause, however, will vary depending upon the types of work that the business system is expected to perform.
In the Internet site example, a pegged processor is likely to result in applications interfacing with Internet users to become stalled or unusable and transaction throughput to stall or become exceedingly slow. In the corporate payroll system, the same pegged processor may result in critical software applications that make up the payroll application stalling or becoming exceedingly slow. The causes of the pegged processor may also be different depending upon the usage of the computer. An Internet server""s processor may become pegged due to receiving more requests from Internet users than can be handled. The corporate payroll system""s processor may have become pegged due to multiple processor-intensive business applications running simultaneously on the system.
Computers are often linked to one another using a network, such as a local area network (LAN), wide area network (WAN), or other types of networks such as the Internet. By linking computers, one computer can use resources owned by another computer system. These resources can include files stored on nonvolatile storage devices and resources such as printers. Smaller computers used by an individual (client computers) are often linked to more powerful computers, called servers, that provide large file systems, larger processing capabilities, and resources not typically found on client computers. Servers may be larger PCs, workstations, or mainframe computer systems.
As computer technology continues to proliferate in society and organizations in particular, computer systems and networks likewise increase in complexity. Computing power in an organization is often distributed with servers residing in multiple locations. Operators utilize diagnostic tools and other system tools to remotely learn of conditions occurring in remote systems and to remotely correct those conditions using their available knowledge and resources. Operators may also be distributed with some operators residing at one location while others reside at a different location. In addition, operators in smaller organizations may be xe2x80x9con callxe2x80x9d during weekends and non-business hours. In these environments, an operator may receive a page or call at home regarding a system problem. Using networking technology, the operator preferably logs on to the computer system from a PC at his or her home and resolves the problem from home rather than taking the additional time to travel to the office to handle the problem.
When handling a problem, system operators use various methods to record system problems and the corresponding solutions to those problems. One method used is to keep a computer or paper based system log. The operator writes or types the situations that occur on the computer system, what was done to correct the situation, and the result or outcome of their efforts. When a condition is discovered in the computer system, the operators review their logs for notes concerning any previous occurrences of the condition. If a previous entry is found, the operators use the recorded solution in order to attempt to resolve the condition.
Challenges with paper based logs are that they are maintained in one location. As discussed above, operators are often distributed from both each other and from the systems that they maintain. An operator that receives a call at home is unable to access a paper based log unless a copy is maintained at his home. Operators that are remote from one another are unable to view each other""s notes without faxing or otherwise transmitting the paper based information.
Another challenge with computer based logs is that they often have difficulty accurately capturing all of the data relating to the problem. Operators often rely upon memory to reconstruct the problem that was encountered and solved. Relying upon memory introduces errors as certain details may be forgotten or inaccurately transcribed. In addition, while a computer based log is typically easier to access remotely, many manual steps must still be employed to capture the data and launch corrective actions. In addition, operators are often too busy to maintain the logs effectively. Outdated solutions may remain in the log causing confusion amongst newer operators that do not know that conditions have changed. Furthermore, if multiple operators are working on the same problem multiple updates to the log may occur causing further problems to the computer based log. One of the greatest challenges is tying log notes to the event, tying the event to the problem, and tying the solution to the problem. Another related challenge is capturing solution practices and identifying when a practice is outdated, solid, or when a practice is the best practice but not solid.
What is needed, therefore, is a system and method to assist operators in addressing system conditions and problems using an object based action diary.
It has been discovered that an action diary can improve handling of system events, tasks and operator observations. An action diary includes best practice information that is updated by the system and by the operator as appropriate. Operators use the information stored in the action diary to handle system events and tasks. In addition, responses to events and tasks can be automated so that an automated response occurs when a certain event or task is detected. As knowledge of a computer system improves over time, the knowledge is captured in the action diary. In this manner, the action diary corresponds to the lifecycle of best practices of handling events and tasks. New or different events and tasks are more readily understood and handled by using prior knowledge contained in the action diary. As knowledge of a particular task or situation improves, the corresponding action diary information also improves. General understanding of a type of event or task can be used to create increasingly particularized action diaries that correspond to a more particular problem, event, or task.
It has further been discovered that action diary objects include system and methods for managing action diary objects based on actions, events, and tasks through a lifecycle. A system administrator can setup the system to generate a specific action diary instance and associate it with another object instance. The operator can update the action diary to indicate comments and actions taken in handling an event. Periodically, the system administrator may review the action diaries and edit them for best current practices. A method is provided for creating and maintaining an action diary such that multiple data object types can become part of the action diary and can be organized and maintained as appropriate throughout the lifecycle of the best practice. The user can create an action diary to be associated with a specific type of object or class of objects so that when the indicated object is created, the action diary is available to the operator who will be handling the object. The operator may create a new action diary and associate it with another, already existing object. The new action diary will be created with system policy pre-set defaults which may include automatically creating certain documentation fields such as timestamp, creator, and associated object link and may place these fields in policy pre-determined locations. The operator can select from a palette of objects such as a text box or action and place the object into the action diary first page. The action object may require additional input from the operator to run such as adding specific command parameters. The operator can place objects within the action diary as appropriate for describing the actions taken to handle the situation. In early stages of best practice discovery, operators may try new actions or a series of actions. An action-capture object captures the actions performed by the operator and associates the captured actions with an action diary which is associated with a particular object or class of object. The operator opens an existing action diary or creates a new action diary. An action-capture object captures the operator input until it is turned off. Parameters associated with captured actions are also associated with the action and stored with the action diary. As action diary objects progress through a lifecycle, highlighting (such as shading) of visual representations of action diary approaches indicate the maturity stage of a particular approach within the lifecycle.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.